Blocking/unblocking algorithms for signaling optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols

ABSTRACT

A method of optimizing traffic on a mobile device includes determining that an application is inactive based on historical behavior of the application and blocking traffic originating from or directed towards the application that is determined to be inactive based on historical behavior. A related mobile device is also provided.

PRIORITY CLAIM

This application is a continuation of U.S. patent application Ser. No.17/176,253, filed Feb. 16, 2021, being issued as U.S. Pat. No.11,288,093 on Mar. 29, 2022, which is a continuation of U.S. patentapplication Ser. No. 16/131,549, filed Sep. 14, 2018, now U.S. Pat. No.10,944,686, issued Mar. 9, 2021, which is a continuation of U.S. patentapplication Ser. No. 14/748,226, filed Jun. 23, 2015, now U.S. Pat. No.10,097,477, issued Oct. 9, 2018, which is a continuation ofInternational Patent Application Serial No. PCT/US14/40772, filed Jun.3, 2014, which claims the benefit of U.S. Provisional Patent ApplicationSer. No. 61/830,570, filed Jun. 3, 2013 and U.S. Provisional PatentApplication Ser. No. 61/836,096, filed Jun. 17, 2013; the disclosures ofeach of which are incorporated herein by reference in their entireties.

TECHNICAL FIELD

This disclosure relates to signaling optimization in a wireless network.More specifically, it relates to blocking/unblocking algorithms forsignaling optimization in a wireless network for traffic utilizingproprietary and non-proprietary protocols.

BACKGROUND

An increasing amount of mobile traffic is moving to vendor-specificproprietary protocols. Examples include Google's traffic over TCP port5228, WhatsApp, Urban Airship push notifications used by variousapplication vendors, Skype, Yahoo Mail 2.0 etc. This means that more andmore of the application traffic that causes signaling now includessignificant contribution from proprietary protocols on top of trafficutilizing standardized protocols such as HTTP/HTTPS. Conventionaloptimization of signaling relies upon some understanding of the protocolbeing used. Thus, there is a clear need for the ability to optimizesignaling even for arbitrary, proprietary, and/or non-standardprotocols, e.g., where the underlying protocol definition may beunknown.

SUMMARY

The subject matter disclosed herein includes an architecture (e.g., thedistributed system comprised of the local proxy and/or the proxy server)to optimize signaling for arbitrary, proprietary, and/or non-standardprotocols, in addition to standard protocols such as HTTP or HTTPS viablocking and/or unblocking algorithms.

According to one aspect, the subject matter described herein includes amethod for signaling optimization in a wireless network utilizingproprietary and non-proprietary protocols. The method includesestablishing a first session between an application on a mobile deviceand a local proxy on the mobile device, establishing a second sessionbetween the local proxy and a proxy server not located on the mobiledevice, and establishing a third session between the proxy server and acontent server. The method also includes monitoring a byte streampresent within the first and second sessions to identify patterns withinthe byte stream, and, in response to identifying a pattern within thebyte stream, determining a behavior of the application based on thepattern, determining whether the behavior of the application is acandidate behavior for optimization, and, if so, performing signalingoptimization between the application and the content server, whereperforming signaling optimization includes dismantling the secondsession, replaying the pattern to the application via the first session,and replaying the pattern to the content server via the third session.

According to another aspect, the subject matter described hereinincludes a system for signaling optimization in a wireless networkutilizing proprietary and non-proprietary protocols. The system includesa mobile device that includes an application and a local proxy, a proxyserver not located on the mobile device, and a content server. A firstsession is established between the application and the local proxy, asecond session is established between the local proxy and the proxyserver, and a third session between the proxy server and the contentserver. A byte stream present within the first and second sessions ismonitored to identify patterns within the byte stream. If a pattern isidentified, the behavior of the application is determined based on thatpattern. If that behavior is a candidate for optimization, then asignaling optimization is performed between the application and thecontent server, including dismantling the second session, replaying thepattern to the application via the first session, and replaying thepattern to the content server via the third session.

According to another aspect, the subject matter described hereinincludes a computer program product for signaling optimization in awireless network utilizing proprietary and non-proprietary protocols.The computer program product includes a non-transitory computer readablestorage medium having computer readable code embodied therewith, thecomputer readable code configured for establishing a first sessionbetween an application on a mobile device and a local proxy on themobile device, establishing a second session between the local proxy anda proxy server not located on the mobile device,

establishing a third session between the proxy server and a contentserver, monitoring a byte stream present within the first and secondsessions to identify patterns within the byte stream, and, in responseto identifying a pattern within the byte stream, determining a behaviorof the application based on the pattern, determining whether thebehavior of the application is a candidate behavior for optimization,and, if so, performing signaling optimization between the applicationand the content server, where performing signaling optimization includesdismantling the second session, replaying the pattern to the applicationvia the first session, and replaying the pattern to the content servervia the third session.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the subject matter described herein will now be explainedwith reference to the accompanying drawings, wherein the like referencenumerals represent like parts, of which:

FIG. 1A-1 depicts a diagram of an example pattern showing recurring 175bytes upstream and 297 bytes downstream, extracted from an applicationthat utilizes a proprietary or non-standard protocol;

FIG. 1A-2 depicts a diagram of an example pattern showing periodic 8/8byte transactions, extracted from byte streams from an application thatutilizes a proprietary or non-standard protocol;

FIG. 1A-3 depicts a diagram of an example pattern showing recurringtransaction inside a Secure Socket Layer (SSL) stream, extracted frombyte streams from an application that utilizes a proprietary ornon-standard protocol;

FIG. 1A-4 and FIG. 1A-5 depict first and second halves, respectively, ofan exemplary table listing example transaction data and patternsdetermined from analyzing of byte streams going to and/or received fromapplications utilizing proprietary, non-proprietary and/or encryptingprotocols according to an embodiment of the subject matter describedherein;

FIG. 1B illustrates an example diagram of a system for implementingblocking/unblocking algorithms for signaling optimization in a wirelessnetwork for traffic utilizing proprietary and non-proprietary protocolsaccording to an embodiment of the subject matter described herein;

FIG. 1C illustrates an example diagram of a proxy and cache systemdistributed between the host server and device which facilitates networktraffic management between a device, an application server or contentprovider, or other servers such as an ad server, promotional contentserver, an e-coupon server or messaging servers such as the GCM serverand the EAS server for resource conservation and content cachingaccording to an embodiment of the subject matter described herein;

FIG. 1D illustrates an example diagram of the logical architecture of adistributed proxy and cache system according to an embodiment of thesubject matter described herein;

FIG. 1E illustrates an example diagram showing the architecture ofclient side components in a distributed proxy and cache system having anapplication/server stabilizer component for optimizing signaling in awireless network for traffic utilizing proprietary (non-standard) andnon-proprietary (e.g., HTTP) protocols according to an embodiment of thesubject matter described herein;

FIG. 1F illustrates a diagram of the example components on the serverside of the distributed proxy and cache system according to anembodiment of the subject matter described herein;

FIG. 2A depicts a block diagram illustrating another example ofclient-side components in a distributed proxy and cache system, furtherincluding a proprietary/non-standard protocol adaptation engine and anapplication blocking/unblocking module according to an embodiment of thesubject matter described herein;

FIG. 2B depicts a block diagram illustrating additional components inthe proprietary/non-standard protocol adaptation engine and theapplication blocking/unblocking module shown in the example of FIG. 2;

FIG. 3A depicts a block diagram illustrating an example of server-sidecomponents in a distributed proxy and cache system, further including aproprietary/non-standard protocol adaptation engine according to anembodiment of the subject matter described herein;

FIG. 3B depicts a block diagram illustrating additional components inthe proprietary/non-standard protocol adaptation engine shown in theexample of FIG. 3A;

FIG. 4A depicts a block diagram illustrating an example of client-sidecomponents in a distributed proxy and cache system residing on a mobiledevice (e.g., wireless device) that manages traffic in a wirelessnetwork (or broadband network) for resource conservation, contentcaching, and/or traffic management according to an embodiment of thesubject matter described herein;

FIG. 4B depicts a block diagram illustrating a further example ofcomponents in the cache system shown in the example of FIG. 4A which iscapable of caching and adapting caching strategies for mobileapplication behavior and/or network conditions according to anembodiment of the subject matter described herein, including componentscapable of detecting long poll requests and managing caching of longpolls;

FIG. 4C depicts a block diagram illustrating additional components inthe application behavior detector and the caching policy manager in thecache system shown in the example of FIG. 4A, which is further capableof detecting cache defeat and perform caching of content addressed byidentifiers intended to defeat cache;

FIG. 4D depicts a block diagram illustrating examples of additionalcomponents in the local cache shown in the example of FIG. 4A which isfurther capable of performing mobile traffic categorization and policyimplementation based on application behavior and/or user activity;

FIG. 5A depicts a block diagram illustrating an example of server-sidecomponents in a distributed proxy and cache system that manages trafficin a wireless network (or broadband network) for resource conservation,content caching, and/or traffic management according to an embodiment ofthe subject matter described herein;

FIG. 5B depicts a block diagram illustrating a further example ofcomponents in the caching policy manager in the cache system shown inthe example of FIG. 5A which is capable of caching and adapting cachingstrategies for mobile application behavior and/or network conditionsaccording to an embodiment of the subject matter described herein,including components capable of detecting long poll requests andmanaging caching of long polls;

FIG. 5C depicts a block diagram illustrating another example ofcomponents in the proxy system shown in the example of FIG. 5A which isfurther capable of managing and detecting cache defeating mechanisms andmonitoring content sources according to an embodiment of the subjectmatter described herein;

FIG. 5D depicts a block diagram illustrating examples of additionalcomponents in proxy server shown in the example of FIG. 5A which isfurther capable of performing mobile traffic categorization and policyimplementation based on application behavior and/or traffic priorityaccording to an embodiment of the subject matter described herein;

FIG. 6 depicts a flow diagram illustrating an example data flow betweena mobile application, a content server, a local proxy and a proxy serverfor optimizing signaling in a wireless network for traffic utilizingproprietary (non-standard) and non-proprietary (standard) protocolsaccording to an embodiment of the subject matter described herein;

FIG. 7 depicts a logic flow diagram illustrating an example methodimplemented on a mobile device for optimizing signaling in a wirelessnetwork for traffic utilizing proprietary (non-standard) andnon-proprietary (standard) protocols according to a first embodiment;

FIG. 8 depicts a logic flow diagram illustrating an example methodimplemented on a mobile device for optimizing signaling in a wirelessnetwork for traffic utilizing proprietary (non-standard) andnon-proprietary (standard) protocols according to a second embodiment;

FIG. 9 depicts a logic flow diagram illustrating an example methodimplemented on a proxy server for optimizing signaling in a wirelessnetwork for traffic utilizing proprietary (non-standard) andnon-proprietary (standard) protocols according to an embodiment of thesubject matter described herein;

FIG. 10A depicts a flow diagram illustrating an example process fordistributed content caching between a mobile device (e.g., any wirelessdevice) and remote proxy and the distributed management of contentcaching according to an embodiment of the subject matter describedherein;

FIG. 10B depicts a timing diagram showing how data requests from amobile device (e.g., any wireless device) to an applicationserver/content provider in a wireless network (or broadband network) canbe coordinated by a distributed proxy system in a manner such thatnetwork and battery resources are conserved through using contentcaching and monitoring performed by the distributed proxy systemaccording to an embodiment of the subject matter described herein;

FIG. 11 depicts a table showing examples of different traffic orapplication category types which can be used in implementing networkaccess and content delivery policies according to an embodiment of thesubject matter described herein;

FIG. 12 depicts a table showing examples of different content categorytypes which can be used in implementing network access and contentdelivery policies according to an embodiment of the subject matterdescribed herein;

FIG. 13 depicts an interaction diagram showing how polls having datarequests from a mobile device (e.g., any wireless device) to anapplication server/content provider over a wireless network (orbroadband network) can be can be cached on the local proxy and managedby the distributed caching system according to an embodiment of thesubject matter described herein;

FIG. 14 depicts an interaction diagram showing how polls for contentfrom an application server/content provider which employscache-defeating mechanisms in identifiers (e.g., identifiers intended todefeat caching) over a wireless network (or broadband network) can bedetected and locally cached according to an embodiment of the subjectmatter described herein;

FIG. 15 depicts a flow chart illustrating an example process forcollecting information about a request and the associated response toidentify cacheability and caching the response according to anembodiment of the subject matter described herein;

FIG. 16 depicts a flow chart illustrating an example process showingdecision flows to determine whether a response to a request can becached according to an embodiment of the subject matter describedherein;

FIG. 17 depicts a flow chart illustrating an example process fordetermining potential for cacheability based on request periodicityand/or response repeatability according to an embodiment of the subjectmatter described herein;

FIG. 18 depicts a flow chart illustrating an example process fordynamically adjusting caching parameters for a given request or clientaccording to an embodiment of the subject matter described herein;

FIG. 19 depicts a flow chart illustrating example processes forapplication and/or traffic (data) categorization while factoring in useractivity and expectations for implementation of network access andcontent delivery policies according to an embodiment of the subjectmatter described herein;

FIG. 20A depicts a flow chart illustrating example processes forhandling traffic which is to be suppressed at least temporarilydetermined from application/traffic categorization according to anembodiment of the subject matter described herein;

FIG. 20B depicts a flow chart illustrating an example process forselection of a network configuration for use in sending traffic based onapplication and/or traffic (data) categorization according to anembodiment of the subject matter described herein;

FIG. 20C depicts a flow chart illustrating an example process forimplementing network access and content delivery policies based onapplication and/or traffic (data) categorization according to anembodiment of the subject matter described herein;

FIG. 21 depicts a flow chart illustrating an example process for networkselection based on mobile user activity or user expectations accordingto an embodiment of the subject matter described herein;

FIG. 22 depicts a data timing diagram showing an example of detection ofperiodic request which may be suitable for caching according to anembodiment of the subject matter described herein;

FIG. 23 depicts a data timing diagram showing an example of detection ofchange in request intervals and updating of server polling rate inresponse thereto according to an embodiment of the subject matterdescribed herein;

FIG. 24 depicts a data timing diagram showing an example of servingforeground requests with cached entries according to an embodiment ofthe subject matter described herein;

FIG. 25 depicts a data timing diagram showing an example of the possibleeffect of cache invalidation that occurs after outdated content has beenserved once again to a requesting application according to an embodimentof the subject matter described herein;

FIG. 26 depicts a data timing diagram showing cache management andresponse taking into account the time-to-live (TTL) set for cacheentries according to an embodiment of the subject matter describedherein; and

FIG. 27 shows a diagrammatic representation of a machine in the exampleform of a computer system within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed.

DETAILED DESCRIPTION

The following description and drawings are illustrative and are not tobe construed as limiting. Numerous specific details are described toprovide a thorough understanding of the disclosure. However, in certaininstances, well-known or conventional details are not described in orderto avoid obscuring the description. References to one or an embodimentin the present disclosure can be, but not necessarily are, references tothe same embodiment; and, such references mean at least one of theembodiments.

Reference in this specification to “one embodiment” or “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiment is included in at least one embodimentof the disclosure. The appearances of the phrase “in one embodiment” invarious places in the specification are not necessarily all referring tothe same embodiment, nor are separate or alternative embodimentsmutually exclusive of other embodiments. Moreover, various features aredescribed which may be exhibited by some embodiments and not by others.Similarly, various requirements are described which may be requirementsfor some embodiments but not other embodiments.

The terms used in this specification generally have their ordinarymeanings in the art, within the context of the disclosure, and in thespecific context where each term is used. Certain terms that are used todescribe the disclosure are discussed below, or elsewhere in thespecification, to provide additional guidance to the practitionerregarding the description of the disclosure. For convenience, certainterms may be highlighted, for example using italics and/or quotationmarks. The use of highlighting has no influence on the scope and meaningof a term; the scope and meaning of a term is the same, in the samecontext, whether or not it is highlighted. It will be appreciated thatsame thing can be said in more than one way.

Consequently, alternative language and synonyms may be used for any oneor more of the terms discussed herein, nor is any special significanceto be placed upon whether or not a term is elaborated or discussedherein. Synonyms for certain terms are provided. A recital of one ormore synonyms does not exclude the use of other synonyms. The use ofexamples anywhere in this specification including examples of any termsdiscussed herein is illustrative only, and is not intended to furtherlimit the scope and meaning of the disclosure or of any exemplifiedterm. Likewise, the disclosure is not limited to various embodimentsgiven in this specification.

Without intent to limit the scope of the disclosure, examples ofinstruments, apparatus, methods and their related results according tothe embodiments of the present disclosure are given below. Note thattitles or subtitles may be used in the examples for convenience of areader, which in no way should limit the scope of the disclosure. Unlessotherwise defined, all technical and scientific terms used herein havethe same meaning as commonly understood by one of ordinary skill in theart to which this disclosure pertains. In the case of conflict, thepresent document, including definitions will control.

Existing signaling optimization systems and methods for reducing mobilenetwork congestion can optimize mobile traffic over standard andnon-proprietary application level protocols including, but not limitedto: Hypertext Transfer Protocol (HTTP), Hypertext Transfer ProtocolSecure (HTTPS), File Transfer Protocol (FTP), Simple Mail TransferProtocol (SMTP), Internet Message Access Protocol (IMAP), Post OfficeProtocol (POP), and the like. However, many mobile applications aremoving away from the standard protocols towards vendor specificproprietary protocols. For example, Google utilizes a non-standardTransmission Control Protocol (TCP) port 5228. By way of anotherexample, the “WhatsApp” mobile application uses a customized version ofthe Extensible Messaging and Presence Protocol (XMPP). Similarly, someapplications such as Skype and Yahoo mail use their own proprietaryprotocols, while others such as Urban Airship's push notificationsprotocol is used by various vendors.

Existing signaling optimization systems and methods replay or replicateentire transaction as instructed by a client, which means that theserver performing the signal optimization needs to establish any session(TCP socket and any application level handshakes, Secure Sockets Layer(SSL), etc.) autonomously. However, to do so, the protocols must be wellunderstood. For example, the header and other protocol specific datamust be known before any optimization can be performed. As proprietaryprotocols are not standardized and not well understood, mobile trafficover such proprietary protocols cannot be optimized by existingoptimization systems and methods.

Embodiments of the present disclosure include applicationblocking/unblocking algorithms for signaling optimization in a wirelessnetwork for traffic utilizing both proprietary and non-proprietaryprotocols. The disclosed technology includes an architecture (e.g., adistributed system comprised of a local proxy and/or a proxy server)that optimizes signaling for arbitrary, proprietary, and/or non-standardprotocols, in addition to standard protocols such as HTTP, HTTPS, FTP,SMTP, IMAP, POP, XMPP, and the like in one embodiment. In a furtherembodiment, the disclosed technology provides a protocol agnosticsystems and methods for signaling optimization for any traffic in awireless network.

In one embodiment, a Transmission Control Protocol (TCP) stream ispassed as a byte stream from an application to a local proxy over afirst session, from the local proxy to a proxy server over a second TCPsession, and from the proxy server to a content server over a third TCPsession. The local proxy observes and identifies patterns within thebyte stream, without being aware of the underlying protocol. Once apattern is identified, the second TCP session is torn down such that thefirst TCP session replays the pattern to the application, and third TCPsession replays the pattern to the content server. Once either sidedetects a change in the pattern, the second TCP session isre-established to deliver the changed content to the other end.

When it is not possible to identify a pattern within a byte stream andperform a direct replay of the binary transactions, and/or in additionto the TCP stream optimization, the disclosed innovation herein providesapplication blocking/unblocking strategies that can optimize signalingin the wireless network for traffic utilizing various proprietary andnon-proprietary protocols.

Embodiments of the present disclosure include systems and methods foroptimizing signaling in a wireless network for traffic utilizingproprietary and/or non-proprietary protocols by blocking/unblockingvarious types of applications and/or traffic and triggering reconnectingof applications. These keepalive strategies facilitate management oftraffic and/or resource conservation between mobile devices (e.g.,wireless devices) and a remote server such as an application server,content provider or a messaging server (e.g., Google Cloud Messaging(GCM) server, Exchange ActiveSync (EAS) server) via the distributedproxy system.

FIG. 1A-1 depicts a screen shot 160 of an application for capturingand/or analyzing network traffic, showing the detection of an examplepattern produced by an application “Whatsapp” 162, which utilizes aproprietary or non-standard protocol. Screen shot 160 shows thedetection of a recurring pattern 164 a that includes 175 bytes upstream(to the application) and 297 bytes downstream (from the application.)This pattern occurs periodically, as can be seen in the activity graph164 b.

FIG. 1A-2 depicts another screen shot 166 of an application forcapturing and/or analyzing network traffic, showing the detection of anexample pattern produced by another application, “com.sina.weibo” 168,which also uses a proprietary or non-standard protocol. Screen shot 166shows the detection of a recurring pattern showing periodic 8/8 bytetransactions 170 a and 170 b. This pattern also occurs periodically, ascan be seen in the activity graph 170 c.

FIG. 1A-3 depicts yet another screen shot 172 of an application forcapturing and/or analyzing network traffic, showing the detection of anexample pattern detected within a Secure Socket Layer (SSL) streamextracted from byte streams from an application “com.google.android.gms”174 that utilizes a proprietary or non-standard protocol. Screen shot172 shows the detection of a recurring pattern (176 a, 176 b) thatincludes 680 bytes upstream and 1268 bytes downstream. This pattern alsooccurs periodically, as can be seen in the activity graph 176 d.

FIG. 1A-4 and FIG. 1A-5 depict the top and bottom portions,respectively, of a table 178 listing example transaction data andpatterns determined from analyzing of byte streams going to and/orreceived from applications utilizing proprietary, non-proprietary and/orencrypting protocols according to an embodiment of the subject matterdescribed herein. As can be seen in FIG. 1A-4, a system implementing theconcepts described herein can identify and process various protocols,including an unknown protocol operating over TCP 178 a, http over TCP178 b, and SSL over TCP 178 c. Other protocols listed in table 178include DNS over TCP.

FIG. 1B illustrates an exemplary system for implementingblocking/unblocking algorithms for signaling optimization in a wirelessnetwork for traffic utilizing proprietary and non-proprietary protocolsaccording to an embodiment of the subject matter described herein. Inthe embodiment illustrated in FIG. 1B, a system includes a host server100 that facilitates management of traffic, content caching, and/orresource conservation between mobile devices (e.g., wireless devices),an application server or content provider 110, or other servers such asan ad server 120A, a promotional content server 120B, an e-coupon server120C, or messaging servers such as the Google Cloud Messaging (GCM)server and the Exchange ActiveSync (EAS) server in a wireless network(or broadband network) 108 for resource conservation. Host server 100can further optimize signaling in a wireless network 106 for trafficutilizing proprietary (non-standard) and non-proprietary (e.g., HTTP)protocols.

In the embodiment illustrated in FIG. 1B, host server 100 includes aserver cache 135 for storing periodic and/or often-used signalingmessages, for example. In one embodiment, a network subscriber 103 mayuse a mobile device 150 that includes its own local cache 185 forstoring periodic or often-used signaling messages. Mobile device 150 mayinclude a user interface 104 by which subscriber 103 may use toconfigure mobile device 150 appropriately. In the embodiment illustratedin FIG. 1B, for example, mobile device 150 may connect to mobile network106 through a cell phone tower 112 or other network access equipment.

FIG. 1C illustrates an exemplary system for implementingblocking/unblocking algorithms for signaling optimization in a wirelessnetwork for traffic utilizing proprietary and non-proprietary protocolsaccording to another embodiment of the subject matter described herein.In the embodiment illustrated in FIG. 1C, host server 100 includes notonly server cache 135 but also a proxy server 125. Likewise, mobiledevice 150 includes not only local cache 185 but also a local proxy 175.In one embodiment, network 108 may include an optional caching proxyserver 199. The proxy system distributed among the host server and thedevice can further optimize signaling in a wireless network for trafficutilizing proprietary (non-standard) and non-proprietary (e.g., HTTP)protocols. An example of optimization by the proxy system will bedescribed in more detail below.

FIG. 1D illustrates an exemplary system for implementingblocking/unblocking algorithms for signaling optimization in a wirelessnetwork for traffic utilizing proprietary and non-proprietary protocolsaccording to yet another embodiment of the subject matter describedherein. FIG. 1D illustrates an example diagram of the logicalarchitecture of a distributed proxy and cache system. In the embodimentillustrated in FIG. 1D, a radio access network 112 allows mobile device150 to access the Internet or other data and/or telecommunicationsnetwork via third party PEP/caching proxy 199. The solid lines representnon-optimized signaling traffic, while dotted lines represent optimizedtraffic. A client-side proxy 175 located on or within mobile device 175communicates with a server-side proxy 125. In the embodiment illustratedin FIG. 1D, server-side proxy 125 may communicate optimized traffic witha Short Message Service Center (SMSC) 162, which communicates in eitheran optimized or non-optimized manner to client side proxy 175. In oneembodiment, a reporting and usage analytics entity 174 may communicatewith server-side proxy 125.

FIG. 1E illustrates in more detail a portion of an exemplary system forimplementing blocking/unblocking algorithms for signaling optimizationin a wireless network for traffic utilizing proprietary andnon-proprietary protocols according to yet another embodiment of thesubject matter described herein. FIG. 1E illustrates an example diagramshowing the architecture of client side components in a distributedproxy and cache system having an application/server stabilizer componentfor optimizing signaling in a wireless network for traffic utilizingproprietary (non-standard) and non-proprietary (e.g., HTTP) protocols.In the embodiment illustrated in FIG. 1E, a mobile device, such asmobile device 150, includes a radio/battery information module 161, amobile operating system 162, and multiple applications 163, collectivelyreferred to as “mobile OS and apps” 165. In one embodiment, client sideproxy 175 includes a device state monitor 121, a traffic recognizer 122,a protocol optimizer 123, a traffic scheduler 124, a policy manager 129,a reporting agent 126, a watchdog module 127, and a push client 128 thatcommunicates with a server side proxy 128 via the network. In theembodiment illustrated in FIG. 1E, client side proxy 175 includes localdata cache 185 and an application blocking/unblocking module 186.

FIG. 1F illustrates in more detail a portion of an exemplary system forimplementing blocking/unblocking algorithms for signaling optimizationin a wireless network for traffic utilizing proprietary andnon-proprietary protocols according to yet another embodiment of thesubject matter described herein. FIG. 1F illustrates a diagram of theexample components on the server side of the distributed proxy and cachesystem. In the embodiment illustrated in FIG. 1F, proxy server 125includes a relay server 142 that communicates with client side proxy175. In one embodiment, relay server 142 includes a user database and anotification server 141. In the embodiment illustrated in FIG. 1F, proxyserver 125 also includes local data storage 130, a traffic harmonizer144, and a polling server 145. A policy management server that includesa policy management server database is also included. Some or all of thevarious components within proxy server 125 may communicate informationto and from reporting and usage analytics system 174.

FIGS. 2A and 2B illustrate in more detail a portion of an exemplarysystem for implementing blocking/unblocking algorithms for signalingoptimization in a wireless network for traffic utilizing proprietary andnon-proprietary protocols according to yet another embodiment of thesubject matter described herein. FIG. 2A depicts a block diagramillustrating another example of client-side components in a distributedproxy and cache system, further including a proprietary/non-standardprotocol adaptation engine and an application blocking/unblockingmodule.

In the embodiment illustrated in FIG. 2A, mobile device 250 includesboth a proxy-unaware mobile application 210 and a proxy-aware mobileapplication 220. The proxy aware mobile application 220 communicateswith local proxy 275 via a proxy application programming interface (API)225. In the embodiment illustrated in FIG. 2A, mobile device 250 alsoincludes an OS 204, a context API 206, a network interface 208 thatincludes interface modules for SMS, WiFi, cellular, etc., and a cache285.

In the embodiment illustrated in FIG. 2A, local proxy 275 includes auser activity module 215, a caching policy manager 245 that includes aapplication protocol module 248, a traffic shaping engine 255 thatincludes an alignment module 256 and a batching module 257, a connectionmanager 265 that includes a radio controller 266 and a heartbeat manager267, and a request transaction manager 235 that includes an applicationbehavior detector 236. In one embodiment, application behavior detector236 includes a pattern detector 237, an application profile generator239, and a prioritization engine 241.

In the embodiment illustrated in FIG. 2A, mobile device 250 includes aproprietary/non-standard protocol adaptation engine 401 and anapplication blocking/unblocking module 470, which are are described inmore detail in FIG. 2B.

FIG. 2B depicts a block diagram illustrating additional components inthe proprietary/non-standard protocol adaptation engine and theapplication blocking/unblocking module shown in the example of FIG. 2A.

In the embodiment illustrated in FIG. 2B, adaptation engine 401 includesa transaction detection engine 402 that includes a protocol analyzer406, a transaction pattern detection engine 403, and a binary matchingan normalization engine 405. Adaptation engine 401 also includes arouting rule optimizer 442, a pattern replay module 444, an applicationbyte stream generator 411, a byte stream pattern recognition engine 439,a pattern change detection engine 441, a session manager 413, aheartbeat manager 443, and a protocol encoding/decoding module 445.

In the embodiment illustrated in FIG. 2B, applicationblocking/unblocking module 470 includes a keepalive intensiveapplication blocking/unblocking module 472, a least complaintblocking/unblocking module 474, a UDB traffic blocking/unblocking module476, an idle application traffic blocking/unblocking module 478, and anapplication reconnect trigger module 479. The operation of applicationblocking/unblocking module 470 will be described in more detail, below.

In the embodiment illustrated in FIG. 2B, both adaptation engine 401 andapplication blocking/unblocking module 470 communicate with each otherand both have access to local cache 485.

FIGS. 3A and 3B illustrate an exemplary system for implementingblocking/unblocking algorithms for signaling optimization in a wirelessnetwork for traffic utilizing proprietary and non-proprietary protocolsaccording to another embodiment of the subject matter described herein.FIG. 3A depicts a block diagram illustrating an example of server-sidecomponents in a distributed proxy and cache system, further including aproprietary/non-standard protocol adaptation engine.

In the embodiment illustrated in FIG. 3A, a host server 300 provides andcontrols access between mobile devices 350 and various serviceproviders, such as an ad server 520A, a promotional content server 520B,an e-coupon server 520, and the like, as well as other applicationserver/service provider(s) 310. Host server 300 may also have access toa server cache 335.

In the embodiment illustrated in FIG. 3A, host server 300 includes anetwork interface 308, a connection and content metadata repository 312,a device information repository 314, a network service providerrepository 316, and a proxy server 325. In the embodiment illustrated inFIG. 3A, network interface 308 includes interface modules for variousnetworks/network protocols, including, for example, an SMS interface, aWiFi interface, and a cellular interface.

In the embodiment illustrated in FIG. 3A, proxy server 325 includes anapplication tracking engine 511, an HTTP access engine 345, a proxycontroller 365, a traffic shaping engine 375, a proprietary/non-standardprotocol adaptation engine 501, a caching policy manager 355, and aconnection manager 395. In one embodiment, HTTP access engine 345includes a new data detector module 347. In one embodiment, proxycontroller 365 includes an activity/behavior awareness module 365, apriority awareness module 367, and a data invalidator module 368. In oneembodiment, traffic shaping engine 375 includes a control protocolmodule 376 and a batching module 377. In one embodiment, caching policymanager 355 includes an application protocol module 356. In oneembodiment, connection manager 395 includes a radio controller 396, aninternet/WiFi controller 397, and a heartbeat manager 398.

FIG. 3B depicts a block diagram illustrating additional components inthe proprietary/non-standard protocol adaptation engine shown in theexample of FIG. 3A. In the embodiment illustrated in FIG. 3B, adaptationengine 501 includes a transaction detection engine 502, a routing ruleoptimizer 542, a replay module 544, an application byte stream generator511, a byte stream pattern recognition engine 539, a pattern changedetection engine 541, a session manager 513, a heartbeat manager 543,and a protocol encoding/decoding module 545. In one embodiment,transaction detection engine 502 includes a protocol analyzer 506, atransaction pattern detection engine 503, and a binary matching andnormalization engine 505. In the embodiment illustrated in FIG. 3B,adaptation engine 501 has access to an application profiles database586.

FIGS. 4A through 4D illustrate in detail a portion of an exemplarysystem for implementing blocking/unblocking algorithms for signalingoptimization in a wireless network for traffic utilizing proprietary andnon-proprietary protocols according to another embodiment of the subjectmatter described herein. FIGS. 4A through 4D depict components of anexemplary mobile device. The mobile device 250 depicted in FIG. 4A isessentially the same as the like-numbered element illustrated in FIG.2A, but without the adaptation engine 401 and applicationblocking/unblocking module 470 shown in FIG. 2A.

FIG. 4A depicts a block diagram illustrating an example of client-sidecomponents in a distributed proxy and cache system residing on a mobiledevice (e.g., wireless device) that manages traffic in a wirelessnetwork (or broadband network) for resource conservation, contentcaching, and/or traffic management. The client-side proxy (or localproxy) can further categorize mobile traffic and/or implement deliverypolicies based on application behavior, content priority, user activity,and/or user expectations.

FIG. 4B depicts a block diagram illustrating a further example ofcomponents in the cache system shown in the example of FIG. 4A which iscapable of caching and adapting caching strategies for mobileapplication behavior and/or network conditions. Components capable ofdetecting long poll requests and managing caching of long polls are alsoillustrated.

In the embodiment illustrated in FIG. 4B, caching policy manager 245includes a metadata generator 203, a local cache invalidator 244, a pollschedule generator 247, an application protocol module 248, a cachelook-up engine 205, an application cache policy repository 243, a cacheappropriateness decision engine 246, and a cache or connect selectionengine 249. In one embodiment, local cache invalidator 244 includes atime to live (TTL) manager 244A. In one embodiment, poll schedulegenerator 247 includes a schedule update engine 247A and a timeadjustment engine 247B. In one embodiment, cache appropriatenessdecision engine 246 includes a timing predictor 246A, a contentpredictor 246B, a request analyzer 246C, and a response analyzer 246D.In one embodiment, cache or connect selection engine 249 includes aresponse scheduler 249A. In the embodiment illustrated in FIG. 4B,metadata generator 203 and cache look-up engine 205 within cachingpolicy manager 245 access cache 285.

In the embodiment illustrated in FIG. 4B, application behavior detector236 includes a poll interval detector 238, a pattern detector 237, anapplication profile generator 239, a prioritization engine 241, and anapplication profile repository 242. In one embodiment, poll intervaldetector 238 includes a long poll detector 238A, which may include arequest/response tracking engine 238B, and a long poll hunting detector238C. In one embodiment, application profile generator 239 includes aresponse delay interval tracker 239A.

In the embodiment illustrated in FIG. 4B, caching policy manager 245 andapplication behavior detector 236 communicate with a blacklist manager201, which has access to both the application cache policy repository243 within caching policy manager 245 and the application profilerepository 242 within application behavior detector 236.

FIG. 4C depicts a block diagram illustrating additional components inthe application behavior detector and the caching policy manager in thecache system shown in the example of FIG. 4A, which is further capableof detecting cache defeat and perform caching of content addressed byidentifiers intended to defeat cache.

In the embodiment illustrated in FIG. 4C, caching policy manager 245includes an identifier normalizer 211 and a cache defeat resolutionengine 211. In one embodiment, identifier normalizer 211 includes acache defeat parameter handler 212 and a hash engine 213. In oneembodiment, cache defeat resolution engine 221 includes a patternextraction module 222 and a cache defeat parameter detector 223. In oneembodiment, cache defeat parameter detector 223 includes a randomparameter detector 224 and a time/date parameter detector 226.

In the embodiment illustrated in FIG. 4C, application behavior detector236 includes a pattern detector 237. In one embodiment, pattern detector237 includes a pattern extraction module 232, a random parameterdetector 233, and a time/date detector 234.

FIG. 4D depicts a block diagram illustrating examples of additionalcomponents within mobile device 250 shown in the example of FIG. 4A,which is further capable of performing mobile traffic categorization andpolicy implementation based on application behavior and/or useractivity. In the embodiment illustrated in FIG. 4D, mobile device 250also includes a backlight detector 219, which is used to determinewhether the user of the mobile device is actively accessing the mobiledevice, and a network configuration selection engine 251.

In the embodiment illustrated in FIG. 4D, network configuration engine251 includes a wireless generation standard selector 251A, a data ratespecifier 251B, an access channel selection engine 251C, and an accesspoint selector 251D.

In the embodiment illustrated in FIG. 4D, user activity module 215includes a user activity tracker 215A, a user activity prediction engine215B, and a user expectation manager 215C. In the embodiment illustratedin FIG. 4D, application behavior detector 236 includes a prioritizationengine 241A, a time criticality detection engine 241B, an applicationstate categorizer 241C, and an application traffic categorizer 241D. Inone embodiment, application state categorizer 241C includes modules fordetecting the state of both foreground and background applications. Inone embodiment, application traffic categorizer 241D includes modulesfor categorizing both interactive traffic and maintenance traffic.

FIGS. 5A through 5D illustrate in detail a portion of an exemplarysystem for implementing blocking/unblocking algorithms for signalingoptimization in a wireless network for traffic utilizing proprietary andnon-proprietary protocols according to another embodiment of the subjectmatter described herein. FIG. 5A depicts a block diagram illustrating anexample of server-side components in a distributed proxy and cachesystem that manages traffic in a wireless network (or broadband network)for resource conservation, content caching, and/or traffic management.The server-side proxy (or proxy server) can further categorize mobiletraffic and/or implement delivery policies based on applicationbehavior, content priority, user activity, and/or user expectations. Thehost server 300 depicted in FIG. 5A is essentially the same as thelike-numbered element illustrated in FIG. 3A, but without the adaptationengine 501 and application tracking engine 511 shown in FIG. 3A.

FIG. 5B depicts a block diagram illustrating a further example ofcomponents in the caching policy manager in the cache system shown inthe example of FIG. 5A which is capable of caching and adapting cachingstrategies for mobile application behavior and/or network conditions.Components capable of detecting long poll requests and managing cachingof long polls are also illustrated. In the embodiment illustrated inFIG. 5B, caching policy manager 355 includes a metadata generator 303, acache look-up engine 305, an application protocol module 356, an updatedor new content detector 359, a response analyzer 361, and a contentsource monitoring engine 357. In the embodiment illustrated in FIG. 5B,content source monitoring engine 357 includes a poll schedule manager358 that includes a host timing simulator 358A, a long poll requestdetector/manager 358B, a schedule update engine 358C, and a timeadjustment engine 358D.

FIG. 5C depicts a block diagram illustrating another example ofcomponents in the proxy system shown in the example of FIG. 5A which isfurther capable of managing and detecting cache defeating mechanisms andmonitoring content sources. In the embodiment illustrated in FIG. 5C,caching policy manager 355 additionally includes a cache defeatingsource manager 352 that includes an identifier modifier module 353 andan identifier pattern tracking module 354.

FIG. 5D depicts a block diagram illustrating examples of additionalcomponents in proxy server 325 shown in the example of FIG. 5A which isfurther capable of performing mobile traffic categorization and policyimplementation based on application behavior and/or traffic priority. Inthe embodiment illustrated in FIG. 5D, traffic shaping engine 375additionally includes an alignment module 378. In the embodimentillustrated in FIG. 5D, proxy server 325 includes a traffic analyzer 336that includes a prioritization engine 341A, a time criticality detectionengine 341B, an application state categorizer 341C, and a trafficcategorizer 341D. In one embodiment, application state categorizer 341Cincludes modules for detecting the state of both foreground andbackground applications. In one embodiment, application trafficcategorizer 341D includes modules for categorizing both interactivetraffic and maintenance traffic.

FIG. 6 depicts a flow diagram illustrating an example data flow betweena mobile application, a content server, a local proxy and a proxy serverfor optimizing signaling in a wireless network for traffic utilizingproprietary (non-standard) and non-proprietary (standard) protocolsaccording to an embodiment of the subject matter described herein. Inthe embodiment illustrated in FIG. 6, system 600 includes a mobileapplication 602, a local proxy 604, a proxy server 325, and a contentserver 608. The process begins with establishment of a first session 610between mobile application 610 and local proxy 604. Local proxy 604 thenestablishes a second session 612 with proxy server 325. Proxy server 325establishes a third session 614 with content server 608. Mobileapplication 602 then communicates with content server 608 via theestablished sessions 610, 612, and 614, starting with completion of ahandshake 616.

When mobile application 602 needs data from content server 608, it sendsa data request 618 to local proxy 604, which forwards the request orgenerates a new request 620 to proxy server 325, which forwards thatrequest or generates its own new request 624 to content server 608.Alternatively, local proxy 604 can send a request 626 directly tocontent server 608, bypassing proxy server 325. Content server 608 sendsa response 628, which passes back to mobile application 602 as messages628, 630, and 632.

After one or more transactions have occurred, local proxy 604 may detecta transaction (request/response) pattern (block 634). In the embodimentillustrated in FIG. 4A, for example, these transaction patterns may bedetected by pattern detector module 237 within request/transactionmanager 235, or by another component within local proxy 604. Likewise,proxy server 325 may detect a transaction pattern (block 366.) In theembodiment illustrated in FIG. 5A, for example, these patterns may bedetected by activity/behavior awareness module 366 within proxycontroller 365 or by another component with proxy server 325.

In response to detecting these transaction patterns, the second sessionis terminated 638. From this point on, local proxy 604 continues toreplay the transaction response (e.g., provide the previously capturedresponse) 604 to mobile application 602, and proxy server 325 continuesto replay the transaction pattern (e.g. provide the previously capturedrequest) 642 to content server 608. In this manner, the interactionsacross the first session between mobile application 602 and local proxy604 will be replicated, as will the interactions across the thirdsession between proxy server 325 and content server 308, without theneed for the second session between local proxy 604 and proxy server325.

FIG. 7 depicts a logic flow diagram illustrating an example methodimplemented on a mobile device for optimizing signaling in a wirelessnetwork for traffic utilizing proprietary (non-standard) andnon-proprietary (standard) protocols according to a first embodiment. Inthe embodiment illustrated in FIG. 7, the process 700 starts at step 702with the establishment of a session with a mobile application. At step704, a session with a proxy server is established, and at step 706, bytestreams from the mobile application are captured. At step 708, themethod includes attempting to identify a transaction pattern from thebyte streams. If a pattern is not detected, the process goes to step710, in which byte streams are routed directly to a content server, andthe process ends. If, at step 708, a pattern is detected, the processgoes to step 712, in which the session with the proxy server is torndown. At step 714, a byte stream from the mobile application iscaptured. At step 716, the byte stream is checked to see if it matches apreviously identified pattern. If so, at step 718 the transactionpattern to the mobile application is replayed, and the process returnsto step 714, where it waits for another byte stream from the mobileapplication. If, at step 716, the byte stream is not a previouslyidentified pattern, the byte stream is identified as changed content(step 720), a new session is established with the proxy server (step722), the changed content is delivered to the content server via theproxy server (step 724), the session with the proxy server is torn downagain (step 726), and monitoring and capturing of byte streams to detecta new pattern continues (step 728.)

FIG. 8 depicts a logic flow diagram illustrating an example methodimplemented on a mobile device for optimizing signaling in a wirelessnetwork for traffic utilizing proprietary (non-standard) andnon-proprietary (standard) protocols according to a second embodiment.In the embodiment illustrated in FIG. 8, process 800 includesestablishing a first session with a mobile application (step 802),establishing a second session with a content server (step 804), andcapturing byte streams from the mobile application (step 806.) At step808, a transaction pattern that is not specific to any protocol isidentified from the byte streams. At step 810, the second session withthe content server is torn down, and at step 812 a session isestablished with a proxy server.

FIG. 9 depicts a logic flow diagram illustrating an example methodimplemented on a proxy server for optimizing signaling in a wirelessnetwork for traffic utilizing proprietary (non-standard) andnon-proprietary (standard) protocols according to an embodiment of thesubject matter described herein. In the embodiment illustrated in FIG.9, process 900 includes establishing a first session with a local proxy(step 902), establishing a second session with a content server (step904), and capturing/caching transaction requests/responses comprisingbyte streams from the local proxy and/or content server (step 906.) Step908 includes receiving a transaction pattern that was identified fromthe byte streams by the local proxy. In response, the session with thelocal proxy is disconnected (step 910), and the process moves to step912.

At step 912, if heartbeats are received from the local proxy, theprocess moves to step 914, in which the session with the content serveris disconnected and the process ends. If, at step 912, heartbeats arereceived from the local proxy, the transaction pattern is replayed tothe content server (step 916) and the process moves to step 918.

At step 918, if a changed byte stream is detected, the session with thelocal proxy is established (step 920), and the byte streams are passedto the local proxy/content server (step 922). In one embodiment, theprocess returns to step 906 and continues from there. If, at step 918, achanged byte stream is not detected, the process returns to step 912 andcontinues from there.

FIG. 10A depicts a flow diagram illustrating an example process fordistributed content caching between a mobile device (e.g., any wirelessdevice) and remote proxy and the distributed management of contentcaching according to an embodiment of the subject matter describedherein. In the embodiment illustrated in FIG. 10A, the process startswhen a request is received (step 1002). The URL is normalized (step1004), and the request is checked to determine whether it is cacheable(step 1006.) If, at step 1006, the request is not cacheable, the requestis sent (step 1008), a response to the request is received (step 1010),and the response is delivered (step 1022.) If, at step 1006, the requestis determined to be cacheable, a cache lookup is performed to see if therequest has been cached (step 1012).

If, at step 1012, the request is not found in the cache, the request issent (step 1016.) When a response to the request is received (step1018), the response is checked to determine whether it is cacheable(step 1026.) If, at step 1026, the response is not cacheable, theresponse is delivered (step 1022.) If the response is cacheable, theresponse is cached (step 1020), the request is polled (step 1014), andthe response is delivered (step 1022.)

If, at step 1012, the request is found in the cache, the cache entry ischecked for validity (step 1024.) If, at step 1024, the request isdetermined to be invalid, the process goes to step 1016 and continuesfrom there. If, at step 1024, the request is determined to be valid, theprocess checks that the request contains a validator (step 1028.) If, atstep 1028, the request contains a validator, then a validating responseis formed (step 1032) and delivered (step 1022). If, at step 1028, therequest does not contain a validator, a response is formed from thecache (step 1030) and delivered (step 1022.)

FIG. 10B depicts a timing diagram showing how data requests from amobile device (e.g., any wireless device) to an applicationserver/content provider in a wireless network (or broadband network) canbe coordinated by a distributed proxy system in a manner such thatnetwork and battery resources are conserved through using contentcaching and monitoring performed by the distributed proxy system. In theembodiment illustrated in FIG. 10B, a distributed proxy system 1060includes a mobile device 1050, a server-side component 1070, and anapplication server/content provider (AS/CP) 1095. In the embodimentillustrated in FIG. 10B, mobile device 1050 includes a home screenwidget 1055 and a local proxy 1065, and server-side components 1070include a caching proxy 1075 and a host server 1085.

In the embodiment illustrated in FIG. 10B, home screen widget 1055issues a data request 1052 to AS/CP 1095, and AS/CP 1095 sends a dataresponse 1054 to home screen widget 1055. In one embodiment, both thedata request and the data response travel through at least one of thelocal proxy 1065, caching proxy 1075, and host server 1085. Local proxy1065 may then issue a proxied data request 1056 to caching proxy 1075,which may respond with a proxied data response 1058.

In the embodiment illustrated in FIG. 10B, home screen widget 1055 maythen issue a monitor data request 1062, which is received by host server1085 and forwarded or reissued as monitor data request 1064 to AS/CP1095. AS/CP 1095 may then issue the same response 1066. If home screenwidget 1055 issues a proxied data request 1068, local proxy 1065 maysatisfy that request by issuing a response from local cache 1072 andthus avoid traffic between mobile device 1050 and server-side components1070. Meanwhile, host server 1085 may continue to issue periodic monitordata requests 1074. If AS/CP 1095 issues a changed response 1076 (i.e.,a response that is different from the previous response 1066), hostserver 1085 forwards the changed response 1076 Thus, when home screenwidget issues the next proxied data request 1082, local proxy 1065 willnot respond from its local cache 1072 but will instead forward the datarequest 1082 to caching proxy 1075, and caching proxy 1075 will satisfythat request from its cache.

FIG. 11 depicts a table showing examples of different traffic orapplication category types which can be used in implementing networkaccess and content delivery policies according to an embodiment of thesubject matter described herein. In the embodiment illustrated in FIG.11, traffic category/application category table 1100 includes a numberof categories, including, but not limited to, interactive traffic versusbackground traffic, applications where the user is waiting for aresponse versus not waiting for a response, applications that are in theforeground versus in the background, and device states where thebacklight is on or off. As will be described in more detail below, inone embodiment, if a device backlight is off, that may be taken as asign that the user is not actively using that device and thereforemaximum signaling optimization, including blocking, may be appropriate.Likewise, if the device backlight is on, that may be an indication thatthe user is actively using the device and therefore signalingoptimization and/or blocking may be curtailed or stopped completely.

FIG. 12 depicts a table showing examples of different content categorytypes which can be used in implementing network access and contentdelivery policies according to an embodiment of the subject matterdescribed herein. In the embodiment illustrated in FIG. 12, contentcategory table 1200 includes a number of categories, including, but notlimited to, high priority content, low priority content, time criticalcontent, and non-time critical content. In one embodiment, some or allof these factors may be taken into account when determining whetheroptimization and/or blocking should or should not be enabled.

FIG. 13 depicts an interaction diagram showing how polls having datarequests from a mobile device (e.g., any wireless device) to anapplication server/content provider over a wireless network (orbroadband network) can be can be cached on the local proxy and managedby the distributed caching system according to an embodiment of thesubject matter described herein. In the embodiment illustrated in FIG.13, at step 1332, Mobile application/widget 1355 polls applicationserver/content provider 1395. At step 1334, local proxy 1365 interceptsthe poll. At step 1336, local proxy 1365 detects that cache content isavailable for the polled content and is valid and thus retrieves aresponse to satisfy the poll. At step 1338, mobile application/widget1355 receives a response to the poll from a cache entry, provided bylocal proxy 1365.

At step 1340, mobile application/widget 1355 again polls applicationserver/content provider 1395. At step 1342, local proxy 1365 interceptsthe poll. At step 1344, local proxy 1365 detects that cache content isunavailable and decides to set up the polled source for caching. At step1346, local proxy 1365 forwards the poll request to the source. At step1348, application server/content provider 1395 receives the poll requestfrom the mobile application/widget 1355 and provides a response tosatisfy the current request. At step 1350, mobile application/widget1355 receives the response to satisfy the request from the applicationserver/content provider 1395.

At step 1352, local proxy 1365 tracks polling frequency of theapplication and sets up a polling schedule for the server-side entity.Server side entities include, but are not limited to, a host server1385, a server cache 1335, and a caching proxy 1375. At step 1354, localproxy 1365 sends the cache setup to the server-side entity. At step1356, the server-side entity receives the cache setup including anidentification of the application server/content provider 1395 to bepolled and a polling schedule. At step 1358, the server-side entitypolls the application server/content provider 1395 to monitor theresponse to the request. At step 1360, application server/contentprovider 1395 receives the poll from the server-side entity and sendsthe response. At step 1362, the server-side entity receives the sameresponse and then polls the application server/content provider 1395again based on the polling schedule. At step 1364, applicationserver/content provider 1395 receives poll from the server-side entityand sends the response. At step 1366, the server-side entity detectschanged or new response and notifies the local proxy 1365 that theresponse has changed since the last time. At step 1368, the server-sideentity stores the new or changed response in the server-side entity. Atstep 1370, local proxy 1365 receives notification that new or changeddata is available, and in response, invalidates the relevant cacheentries.

At step 1372, mobile application/widget 1355 polls applicationserver/content provider 1395. At step 1374, local proxy 1365 determinesthat no valid cache entry is available and requests a response from theserver-side entity. At step 1376, the server-side entity receives therequest for the new response and sends the response to the local proxy1365. At step 1378, the request is satisfied from the server-sideentity, e.g., the server side entity sends the response to mobileapplication/widget 1355.

At step 1380, mobile application/widget 1355 polls applicationserver/content provider 1395. At step 1382, local proxy 1365 determinesthat no valid cache entry is available and forwards the poll to theapplication server/content provider 1395. At step 1384, applicationserver/content provider 1395 receives the poll from local proxy 1365 andsends the response. At step 1386, the request from mobileapplication/widget 1355 is satisfied by the application server/contentprovider 1395.

FIG. 14 depicts an interaction diagram showing how polls for contentfrom an application server/content provider which employscache-defeating mechanisms in identifiers (e.g., identifiers intended todefeat caching) over a wireless network (or broadband network) can bedetected and locally cached according to an embodiment of the subjectmatter described herein. In the embodiment illustrated in FIG. 14, atstep 1432, Mobile application/widget 1455 polls applicationserver/content provider 1495. At step 1434, local proxy 1465 interceptsthe poll and determines that a cache defeating mechanism is beingemployed by server/content provider 1495. At step 1436, local proxy 1465detects that cache content is available for the polled content anddecides to retrieve a response to satisfy the poll. At step 1438, mobileapplication/widget 1455 receives a response to the poll from a cacheentry within local proxy 1465.

At step 1440, mobile application/widget 1455 polls applicationserver/content provider 1495. At step 1442, local proxy 1465 interceptspoll and proxy determines that a cache defeating mechanism is beingemployed by application server/content provider 1495. At step 1444,local proxy 1465 detects that cache content is unavailable and decidesto setup the polled source for caching. At step 1446, local proxy 1465extracts a pattern of an identifier of the request and tracks pollingfrequency of mobile application/widget 1455 and sets up a pollingschedule for the server-side entity, which may be a host server 1485, aserver cache 1435, or a caching proxy 1475, for example. At step 1448,local proxy 1465 forwards the poll request to the source. At step 1450,application server/content provider 1495 receives the poll request andprovides a response to satisfy the current request. At step 1452, mobileapplication/widget 1455 receives from the application server/contentprovider 1495 the response to satisfy the request.

At step 1454, local proxy 1465 caches the response and stores anormalized version of the identifier in association with the receivedresponse for future identification and retrieval. At step 1456, localproxy 1465 sends the cache setup to the server-side entity, includingthe identifier or a normalized version of the identifier. At step 1458,the server-side entity receives the cache setup including anidentification of application server/content provider 1495 to be polledand a polling schedule. At step 1460, the server-side entity pollsapplication server/content provider 1495 to monitor the response to therequest. At step 1462, application server/content provider 1495 receivesthe poll from server-side entity and sends the response. At step 1464,the server-side entity receives the same response and pulls theapplication based on the polling schedule. At step 1466, applicationserver/content provider 1495 receives the poll from the server-sideentity and sends the response. At step 1468, the server-side entitydetects new or changed response and notifies local proxy 1465. At step1470, the server-side entity stores new or changed response in theserver-side entity. At step 1472, local proxy 1465 receives notificationthat new or changed date is available and invalidates the relevant cacheentries.

At step 1474, mobile application/widget 1455 polls applicationserver/content provider 1495. At step 1476, local proxy 1465 determinesthat no valid cache entry is available and retrieves the response fromthe server-side entity. At step 1478, the server-side entity receivesrequest for the new response and sends the response to the local proxy1465. At step 1480, the request from mobile application/widget 1455 issatisfied by the server-side entity.

At step 1482, mobile application/widget 1455 polls applicationserver/content provider 1495. At step 1484, local proxy 1465 determinesthat no valid cache entry is available and forwards the poll toapplication server/content provider 1495. At step 1486, applicationserver/content provider 1495 receives the poll from local proxy 1465 andsends the response. At step 1488, the request from mobileapplication/widget 1455 is satisfied by the application server/contentprovider 1495.

FIG. 15 depicts a flow chart illustrating an example process forcollecting information about a request and the associated response toidentify cacheability and caching the response according to anembodiment of the subject matter described herein. In the embodimentillustrated in FIG. 15, a process for determining whether a response iscacheable includes collecting information about a request andinformation about the response received for the request (step 1502) andthen using the information about either the request initiated (step1504) or the response received (step 1506) to determine whether or notthe request is cacheable (sub-process “A”, described in more detail inFIG. 16, below.) At step 1508, it is determined whether the request iscacheable. If not, the response is not cached (step 1510), and theprocess returns to step 1502. If the request is cacheable, the responseis stored in the cache as a cache entry, including metadata havingadditional information regarding caching of the response (step 1512.)

Once the response has been cached, at least two events can occur. Thefirst event is the detection of a subsequent request (step 1514.) Whenthis happens, a cache look-up is performed in the local cache toidentify the cache entry to be used when responding to the subsequentrequest (step 1516), and the response is served from the cache tosatisfy the subsequent request (step 1518.) The second event is aninvalidation event, in which case it is determined whether the responsecurrently stored in the cache needs to be updated (step 1520.) If so,the response stored in the cache of the mobile device is invalidatedand/or removed from the cache (step 1522.)

FIG. 16 depicts a flow chart illustrating an example process showingdecision flows to determine whether a response to a request can becached according to an embodiment of the subject matter describedherein. The flow chart in FIG. 16 illustrates in more detail thesub-process “A” referred to in FIG. 15. In the embodiment illustrated inFIG. 16, sub-process “A” starts with a determination whether the requestis directed to a black-listed destination (step 1602.) If yes, theresponse is not cached (step 1685.) If the request is not directed to ablack-listed destination, then the process can include analyzing therequest characteristics information associated with the request (step1604), analyzing the response characteristics information associatedwith the response received for the request (step 1606), or both.

In the embodiment illustrated in FIG. 16, request analysis 1604 caninclude a number of tests. For example, the request method may beidentified (step 1608) and the request may be deemed cacheable or notcacheable based on the method (step 1614.) The size of the request maybe checked (step 1610) and a request may be cached if the requestdoesn't exceed a threshold size (step 1616.) In one embodiment, theperiodicity of information between the request and other requestsgenerated by the same client may be determined (step 1612), and requeststhat are identified as periodic are cached while non-periodic requestsare not cached (step 1618.) In one embodiment, requests that satisfy acaching requirement may be cached (step 1695) while those that do notsatisfy any caching requirements are not cached (step 1685.) In analternative embodiment, requests that fail any caching requirement arenot cached, i.e., they must meet all caching requirements before theyare cached.

In the embodiment illustrated in FIG. 16, response analysis 1606 canalso include a number of tests to determine cacheability. For example, aresponse may be identified as cacheable or not cacheable based on itsstatus code (steps 1620 and 1628), based on the size of the response(steps 1622 and 1630), based on whether the response body includesdynamic content (steps 1624 and 1632), and/or whether or not transferencoding is used in the response (step 1626.)

FIG. 17 depicts a flow chart illustrating an example process fordetermining potential for cacheability based on request periodicityand/or response repeatability according to an embodiment of the subjectmatter described herein. In the embodiment illustrated in FIG. 17, theprocess for determining potential cacheability includes both trackingrequests generated by the client to detect periodicity of the requests(step 1702) and tracking responses received for requests generated bythe client to detect repeatability in content of the responses (step1704.)

In the embodiment illustrated in FIG. 17, request tracking 1702 mayinclude determining if there are predictable patterns in the timing ofthe request (step 1706) and/or determining whether request intervalsfall within a tolerance level (step 1708.) If either test returns“true”, the response content can be cached (step 1795); otherwise, theresponse is not cached (step 1785.)

In the embodiment illustrated in FIG. 17, response tracking 1704 mayinclude examining hash values generated from the response bodies of theresponses (step 1710) and/or examining status codes associated with theresponses (step 1712.) If either test indicates that the responses arethe same or that there is a similarity in the content of at least two ofthe responses (step 1714), the response content can be cached (step1795); otherwise, the response is not cached (step 1785.)

FIG. 18 depicts a flow chart illustrating an example process fordynamically adjusting caching parameters for a given request or clientaccording to an embodiment of the subject matter described herein. Inthe embodiment illustrated in FIG. 18, the process for dynamicallyadjusting caching parameters includes tracking requests generated by aclient or directed to a host at the mobile device to detect periodicityof the requests (step 1802.) If it is determined that the requestintervals between two or more requests are the same or approximately thesame (step 1804) or that the request intervals between two more requestsfall within a tolerance level (step 1806), those requests may beidentified as being periodic, and the process may take one or more of anumber of actions.

For example, in the embodiment illustrated in FIG. 18, if a response isreceived for a request that has been identified as being periodic (step1808), that response may be cached as a cache entry in a cache of themobile device (step 1812.) The host may be monitored at a rate to verifyrelevance or validity of the cache entry (step 1814), after which theresponse may be served from the cache to satisfy a subsequent request(step 1816.) In one embodiment, step 1814 may be skipped.

Alternatively or in addition, a rate to monitor a host may be determinedfrom the request intervals (step 1810.) After this, the rate at whichthe given host is monitored to verify relevance or validity of the cacheentry may be set or updated (step 1820). This value may be used by step1814. Alternatively, after step 1810, a change in request intervals forrequests generated by the client may be detected (step 1822), whichtriggers computation of a different rate based on the change in requestintervals (step 1824.)

FIG. 19 depicts a flow chart illustrating example processes forapplication and/or traffic (data) categorization while factoring in useractivity and expectations for implementation of network access andcontent delivery policies according to an embodiment of the subjectmatter described herein. In the embodiment illustrated in FIG. 19, aprocess for application and/or traffic categorization includes detectingnew or changed data available to be sent to a mobile device (step 1902),and, in response, either identifying an application to which the new orchanged data is directed (step 1904), determining the priority or timecriticality of the new or changed data (step 1906), or both.

In the embodiment illustrated in FIG. 19, identification of theapplication 1904 is followed by categorizing the application (step 1906)and then applying one or more tests to determine whether the new orchanged data should be sent to the mobile device (step 1926 followed bysub-flow “B”, which is shown in more detail in FIG. 20B) or suppressed,i.e., not sent to the mobile device (step 1924 followed by sub-flow “A”,which is shown in more detail in FIG. 20A.) For example, the new orchanged data may be sent to the mobile device if the application is inan active state and interacting with a user on the mobile device (step1912) or if the application is running in the foreground on the mobiledevice (step 1914), while an application running in the background wouldbe have its new or changed data suppressed (step 1916.)

In the embodiment illustrated in FIG. 19, the determination of priorityor time criticality 1908 is followed by categorizing the data (step1910) and then applying one or more tests to determine whether the newor changed data should be sent to the mobile device (step 1926) orsuppressed (step 1924.) For example, data may be sent if the data ishigh priority (step 1918), if the data is time critical (step 1920), orif the user is waiting for a response that would be provided in the data(step 1922)—otherwise, the data would be suppressed.

In the embodiment illustrated in FIG. 19, if an application is in anactive state interacting with a user on the mobile device (step 1912) orthe user is waiting for a response that would be provided in data (step1922), an additional sub-flow “C” may be performed. Sub-flow “C” isshown in more detail in FIG. 20C.

FIG. 20A depicts a flow chart illustrating sub-flow “A” in more detail.In the embodiment illustrated in FIG. 20A, data to be suppressed may beheld for a period of time (step 2002) or until there is additional datato be sent (step 2004) before transmitting the new or changed data (step2006.)

FIG. 20B depicts a flow chart illustrating sub-flow “B” in more detail.In the embodiment illustrated in FIG. 20B, other events may trigger theselection process. For example, detection of an activity state of anapplication on the mobile device for which traffic is directed to orfrom (step 2008) may trigger a selection process, as may determining atime criticality of data contained in the traffic to be sent between themobile device and the host server (step 2010.) In the embodimentillustrated in FIG. 20B, sub-flow “B” includes selecting a networkconfiguration for use in sending traffic b between a mobile device and ahost server in the wireless network (step 2012.) Selection may includeselection of a wireless standard (step 2014), such as 2G/2.5G 2022, 3G2024, LTE 2026, or 4G 2028. Selection may also include selection of anaccess channel type (step 2016), such as a forward access channel (FACH)2030 or a dedicated channel (DCH) 2032. Selection may include selectionof a network configuration by data rate (step 2018) or by specifyingdata access points (step 2020.)

FIG. 20C depicts a flow chart illustrating sub-flow “C” in more detail.In the embodiment illustrated in FIG. 20C, the process for implementingnetwork access and content delivery policies based on application and/ortraffic (data) categorization may be triggered by detecting an activitystate of an application on the mobile device for which traffic isdirected to or originated from (step 2034) and/or determination of atime criticality of data contained in the traffic to be sent between themobile device and the host server (step 2036.) In the embodimentillustrated in FIG. 20C, sub-flow “C” includes determining a timing withwhich to allow the traffic to pass through, based on the activity stateor the time criticality (step 2038), followed by controlling radio useon the mobile device based on the timing with which the traffic isallowed to pass through (step 2040) and/or selecting a networkconfiguration in a wireless network for use in passing traffic to andfrom the mobile device (step 2042.)

FIG. 21 depicts a flow chart illustrating an example process for networkselection based on mobile user activity or user expectations accordingto an embodiment of the subject matter described herein. In theembodiment illustrated in FIG. 21, the process for network selectionincludes detection of backlight status of the mobile device (step 2102),detection of user interaction with an application on a mobile device(step 2104), and/or determining whether a user is expecting datacontained in the traffic directed to the mobile device (step 2106.) Fromany of these, the process may go to step 2108, which includesdetermining an activity state of an application on the mobile device forwhich traffic is originated from or directed to, and then to step 2110,which includes selecting whether a 3G, 4G, or LTE network is used insending traffic between a mobile device and a host server in thewireless network.

FIG. 22 depicts a data timing diagram showing an example of detection ofperiodic request which may be suitable for caching according to anembodiment of the subject matter described herein. In the embodimentillustrated in FIG. 22, timeline 2200 shows the detection of a firstrequest at time 01:00. This triggers generation of a cache entry 2202.At time 02:00, one hour later, a second request is detected. In responseto detection of the second request, the cache entry is updated to listthe detected interval, i.e., one hour. From this point on, the systemwill look for a third request at the next interval, e.g., at time 03:00.In the example shown in FIG. 22, the third request arrives a time 03:00.In response to detecting the third request, the local proxy cache maycache the response and notify the proxy server to start sending pollingrequests with the detected interval, e.g., every one hour in thisexample. In one embodiment, the next request may be allowed some amountof variability or jitter and still be detected as a periodic signal(block 2208.) For example, the system may look for the next periodicevent plus or minus 20% of the previous interval, e.g., one hour plus orminus 6 minutes (block 2210.) Thus, in the embodiment illustrated inFIG. 22, the third request could arrive between 02:54 and 03:06 andstill be considered periodic.

FIG. 23 depicts a data timing diagram showing an example of detection ofchange in request intervals and updating of server polling rate inresponse thereto according to an embodiment of the subject matterdescribed herein. In the embodiment illustrated in FIG. 23, timeline2300 shows an example in which a periodic request is detected and thelocal proxy caches the response and requests the proxy server to startsending polling requests at the detected interval, e.g., every hour(block 2302.) The 4^(th) request, however, arrives earlier thanexpected, i.e., 55 minutes after the 3^(rd) request rather than theexpected 60 minutes. The interval still fits within the hour window, sothe window is not adjusted (block 2304.) The 5^(th) request is also 55minutes after the 4^(th) request, which results in the 5^(th) requestfailing to arrive within the allowable window. As a result, the resourceis retrieved from the proxy server, the cache is refreshed, and a startpolling request is resent with an updated interval, i.e., 55 minutesrather than 60 minutes. Window jitter also changes from +/−6 minutes to+/−5 minutes (block 2306.)

FIG. 24 depicts a data timing diagram showing an example of servingforeground requests with cached entries according to an embodiment ofthe subject matter described herein. In the embodiment illustrated inFIG. 24, timeline 2400 shows that upon the detection of a 3^(rd) requestat time 03:00, a periodic request is detected. The client caches theresponse and sends a start polling request with a request interval=1hour (block 2402.) From that point on, a response will be served fromthe cache every hour, i.e., in response to the 4^(th) request receivedat time 04:00 (block 2404) and the 5^(th) request received at time 05:00(block 2406.) In the embodiment illustrated in FIG. 24, a pair offoreground requests also occurs: the first at time 03:10 and the secondat time 03:24. In one embodiment, the cached response data is updatedbut the new interval is not sent to the server (block 2408.)

FIG. 25 depicts a data timing diagram showing an example of the possibleeffect of cache invalidation that occurs after outdated content has beenserved once again to a requesting application according to an embodimentof the subject matter described herein. In the embodiment illustrated inFIG. 25, timeline 2500 shows that upon the detection of a 3^(rd) requestat time 03:00, a periodic request is detected. The client caches theresponse and sends a start polling request with a request interval=1hour (block 2502.) At 03:02, the server receives the poll request andsets the polling interval to one hour (block 2508.) A 4^(th) requestarrives at time 04:00. At time 04:02, the server polls the resource andreceives the same response as last time, i.e., no change. At time 04:20,the resource changes. The 5^(th) request arrives at time 05:00, at whichtime fresh content would have been delivered by the server (block 2504.)At 05:02, the server polls the resource and detects the change incontent. In response, the server sends a cache invalidation notificationto the local proxy (block 2510), which causes the local proxy toinvalidate its cache at time 05:04. The fresh content is then deliveredat the 6^(th) request at time 06:00.

FIG. 26 depicts a data timing diagram showing cache management andresponse taking into account the time-to-live (TTL) set for cacheentries according to an embodiment of the subject matter describedherein. In the embodiment illustrated in FIG. 26, timeline 2600 showsthe response to a series of requests, including creating a cache entryin response to receiving the first request (block 2608), updating thecache entry in response to receiving the second request (block 2610),and identifying the request as periodic, caching the response by theclient, and sending a start polling request with a one hour interval(block 2612.) In the example illustrated in FIG. 26, the response dataTTL value is set to 24 hours (block 2650), which expires at 03:00 thenext day. Timeline 2600 shows the response to the 5^(th) request beingserved from the cache (block 2604.) This will continue until the TTLperiod expires, at which time the response data is removed from thecache. The next request is request 28, at 04:00 the next day, one hourafter the response data was removed from the cache. The period requestwill again be detected, the client caches the response and sends anotherstart polling request with a one hour interval to the server (block2606.)

FIG. 27 shows a diagrammatic representation of a machine in the exampleform of a computer system within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed according to an embodiment of thesubject matter described herein. In the embodiment illustrated in FIG.27, system 2700 includes a processor 2702, a main memory 2704, anon-volatile memory 2706, a network interface device 2708 for connectingto a network 2710, a video display 2712, an alphanumeric input device2714, a cursor control device 2716, a drive unit 2718, and a signalgeneration device 2720, some or all of which communicate via a systembus 2722. In the embodiment illustrated in FIG. 27, processor 2702 andmain memory 2704 include memory for storing machine readableinstructions. Drive unit 2718 includes a machine-readable storage medium2724 for storing machine-readable instructions.

The operation of systems and methods according to embodiments of thesubject matter described herein will now be described in detail.

Blocking Applications that are Keepalive Intensive

In one embodiment, the local proxy identifies keepalives (e.g.,heartbeats) based on a combination of parameters, including, by way ofexample: periodicity, size thresholds, similar/repeating content, and/orbased on knowledge of the actual application level protocol and/orapplications that are keepalive heavy (e.g., applications that send keepalives frequently). The local proxy can then block applications that arekeepalive heavy or (any application that exhibits certain keepalivebehavior) for a given percent of keepalive periods (e.g., via theapplication blocking/unblocking module 470 depicted in FIG. 2B). In oneimplementation, blocking the applications, which blocks keepalive(non-interactive traffic) and other traffic, can include blockingspecific ports for the given percent of keepalive periods. The blockingstrategy can be managed via a policy enforcement module. This blockingstrategy may have a user-impact, cause additional bytes, and/or causeimpacts beyond keepalives. However, the blocking strategy can be refinedusing some of the other keepalive optimization algorithms describedbelow.

In one implementation, the application can be blocked cyclically duringthe screen off period. In other words, the application can be givenaccess for limited periods during the screen off period.

Least-Complaint Blocking

In one embodiment, applications that are inactive (not much happening)are identified and blocked. If, for example, a user is running Skype,but the user has never received/initiated a voice over Internet Protocol(VOIP) call, and all his or her instant messages are clustered, then theapplication can be selected for blocking when the screen is off. Theuser impact is minimized by this strategy since the blocking is based onthe usage history/behavior which indicates that the user has neverdepended on arrival of a call or IM when the screen is off. In additionto the probability of application use based on recent or historicalbehavior, the blocking can be further based on delay time after screenis off, cost of the application, state of the mobile device resources,and the like. In a further embodiment, the least-complaint blocking(e.g., via the least complaint blocking/unblocking module 474 depictedin FIG. 2B) can be designed or customized to define a level ofoptimization desired. For example, the local proxy can start withpolling offload optimization, perform smart connection alignment (i.e.,aligning transactions from different applications on the same radioconnection) and then add least-complaint blocking to get the level ofoptimization desired.

Blocking User Datagram Protocol (UDP) Traffic

In one embodiment, signaling due to applications such as Skype thatutilize the UDP protocol can be reduced or optimized by implementing ablocking strategy that blocks all UDP traffic entirely when the screenis off (immediately or after a configurable delay) (e.g., via the UDPtraffic blocking/unblocking module 476 depicted in FIG. 2B). In oneimplementation, a configuration option that blocks UDP (e.g., Skype UDPtraffic) entirely without regard to the screen state can be provided tofurther reduce signaling due to applications with UDP traffic.

The UDP traffic can be blocked by using iptables rule. For example, UDPtraffic with the Skype app UID can be dropped. To block the UDP, theiptables rule that was added in blocking period can be deleted.

In one implementation, UDP traffic can be blocked when certainconditions are satisfied. For example, when the user is in optimizationmode, when the application (e.g., Skype) is detected or available foroptimization, when the screen is off, and/or a grace period (sinceturning off of the screen) is reached, the UDP traffic can be blocked.To unblock the UDP traffic, one or more conditions may need to besatisfied. Conditions for unblocking can include, screen turn on,application optimization off, optimization mode off, applicationuninstall or upgrade, and/or a combination thereof.

Blocking Application Client Generated Traffic

In one embodiment, signaling due to certain applications (e.g., Spotify)can be reduced by blocking application client generated packets when theapplication is completely idle or not active or performing its function(e.g., when Spotify is not actively playing audio) (e.g., via the idleapplication traffic blocking/unblocking module 478 depicted in FIG. 2B).The application client generated traffic can be unblocked when theapplication moves to the foreground, or starts performing its function(e.g., Spotify starts playing audio). In one implementation, thecomplete idle state can be detected based on keepalive pattern (e.g., 10successive keepalives detected when screen is off, when typically theclient sends a keepalive every one minute). The application traffic canbe blocked using iptables rule and unblocked by removing iptables rules.The blocking can be triggered when the optimization mode is on, theapplication blocking is on and when the screen is off, for example. Theunblocking can be triggered when one or more conditions including screenon, optimization off, application blocking off or applicationuninstalled or upgraded is true.

In one implementation, the signaling optimization of an application(e.g., the Spotify application) can be enabled or disabled by using thePolicy Management System (PMS configuration). In some cases, theheartbeat or keepalive pattern from the application side may vary. Forexample the interval of heartbeats from the application side would beincreased if there were multiple server side initialized heartbeats,though they are 11 bytes also. The complete idle state can then bedetected using time threshold. For example, if continuous 11 bytesheartbeat either in 10 times or 10 minutes in screen off is observed,block the traffic. Or b) if continuous 11 bytes heartbeat either in 12times or 12 minutes regarding the screen status is observed, flag it asblocking and start to block it immediately if it enters into screen off.The logic may be applied in the Wi-Fi network and/or the mobile network.An example logic for detecting a new pattern of the application (e.g.,Spotify) in every configurable duration (e.g., 2 min to a default of 5min) may include:

-   -   1. PMS enabled and not transparent mode    -   2. Got application packet (client or server side)    -   3. All 11 bytes length (client or server side) in this duration,        if one packet's length is not 11, restart the whole detecting        flow    -   4. Screen is off (if screen is on at some time during the 5        minutes, restart the detecting flow)    -   5. No music playing on the phone (detecting when receiving 11        length packet)

For mobile platforms such as the Android platform which provide aservice to monitor the status of an audio playback, the heartbeats canbe monitored and a timer (grace period timer) can be started only whenaudio playback is inactive. In some embodiments, the playback servicestatus can be used to detect whether a media or any other applicationsuch as the Spotify application is in an idle state. While blocking ofapplication client generated traffic has been described with Spotify asan example, the disclosed technology may be generalized, and may beapplicable to various other applications.

Triggering Application's Reconnect

In some applications (e.g. Twitter), users may not expect notificationwhile the screen of their wireless devices is off. The disclosedinnovation can identify such applications, and block data access whilethe screen is off (i.e., user presence is not observed). When the screenis on, or user presence is detected, the application can be unblocked,and an intent (in Android based systems) can be sent to the applicationor broadcast to cause the application to reconnect and sync (e.g., viathe application reconnect trigger module 479 depicted in FIG. 2B). Inone implementation, the connectivity intent can be sent or broadcast ona radio up event.

To reduce signaling due to certain applications (e.g., WhatsApp, Viber),a blocking strategy can be implemented, where, when the applicationmoves to the background, all client generated traffic can be blocked andall server connections can be closed. The application can be unblockedwhen either the application moves to the foreground or a push message(e.g., Google Cloud Messaging (GCM) push message) is received. Whenunblocking, a timer can be started. If the application stays in thebackground beyond a configurable timeout value, the blocking of theapplication can be resumed.

In one embodiment, applications such as Viber and Whatsapp can beblocked whenever the screen is off (or after grace off period of 10seconds). In one implementation, any existing connection initiated bythe applications can be terminated when screen is switched off to ensurethat they do not keep using existing socket connections.

In a further implementation, to further optimize signaling, anapplication that has been blocked can be unblocked when a GCM pushmessage targeted for that application (e.g., WhatsApp, Viber) isdetected or received. In one embodiment, whenever there is incomingtraffic for Google GCM (port 5228), network traffic for the applications(e.g., Whatsapp, Viber, etc.) is allowed for a grace off period (e.g.,10 seconds, 20 seconds or other configurable period) even when thescreen is off, thus allowing them to fetch any incoming data if theyreceive GCM notification. When the screen is on, traffic for theapplications (e.g., Viber and Whatsapp) can be allowed.

The application blocking/unblocking can be illustrated with an exampleuse case, where a user is using a phone actively, the screen is on, andViber keeps TCP socket open. When the user stops using phone, screengoes off. The disclosed system (after grace off period): (a) setsfirewall rule to block any socket connection by either Viber orWhatsapp; (b) terminates any existing socket connection initiated byeither Viber or Whatsapp. When there is some incoming traffic (e.g., forViber), the disclosed system: (a) detects that there is incoming trafficfor Google GCM connection (port 5228); (b) allows traffic (removedfirewall rule to block traffic) for Viber and Whatsapp for short periodof time; (c) Viber is able to connect and receive incoming trafficduring this time window; (d) Viber and Whatsapp connections areterminated and firewall rules are re-enabled until either screen goes onor there is incoming traffic at GCM connection (port 5228).

In one embodiment, the distributed proxy (or the local proxy) can beconfigured to allow traffic on GCM notifications for particularapplications only instead of any incoming GCM traffic. The local proxy,for example, can react only to notification to the particular apps beingoptimized by decoding the GCM traffic. Opening the window for trafficwhen there is GCM traffic should not cause any additional connections(radio is up anyways) and actually the application does not necessarilyuse the window.

In one embodiment, a generic application handlers framework can becreated to optimize signaling behavior of applications such as Viber,Whatsapp, etc. The framework can be implemented on the client side, withlimited, or no server dependencies. For example, on the server sidePolicy Management System (PMS) and PCF can be configured. The frameworkcan be application-agnostic, configurable and/or extendable. Scripts,defined by entrance conditions and actions, and optional exitcondition(s) and action(s) can be used. Various conditions may besupported, and all of the conditions (or in some cases, some of theconditions) may need to be met for an action trigger. Example conditionsinclude timer (initiated for entrance by the exit event and vice versa),radio_timer (same as timer+radio-aware); screen_state (on/off), traffic(triggered by interception of TCP data meeting the defined filter),media_state (on/off), heartbeat_state (on/off), or the like. Actions mayinclude activate/deactivate the rule group(s) by given name(s) and dropsessions meeting the defined filter.

Moreover, while embodiments have been described in the context of fullyfunctioning computers and computer systems, those skilled in the artwill appreciate that the various embodiments are capable of beingdistributed as a program product in a variety of forms, and that thedisclosure applies equally regardless of the particular type of machineor computer-readable media used to actually effect the distribution.

Further examples of machine-readable storage media, machine-readablemedia, or computer-readable (storage) media include, but are not limitedto, recordable type media such as volatile and non-volatile memorydevices, floppy and other removable disks, hard disk drives, opticaldisks (e.g., Compact Disk Read-Only Memory (CD ROMS), Digital VersatileDisks, (DVDs), etc.), among others, and transmission type media such asdigital and analog communication links.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense, as opposed to anexclusive or exhaustive sense; that is to say, in the sense of“including, but not limited to.” As used herein, the terms “connected,”“coupled,” or any variant thereof, means any connection or coupling,either direct or indirect, between two or more elements; the coupling ofconnection between the elements can be physical, logical, or acombination thereof. Additionally, the words “herein,” “above,” “below,”and words of similar import, when used in this application, shall referto this application as a whole and not to any particular portions ofthis application. Where the context permits, words in the above DetailedDescription using the singular or plural number may also include theplural or singular number respectively. The word “or,” in reference to alist of two or more items, covers all of the following interpretationsof the word: any of the items in the list, all of the items in the list,and any combination of the items in the list.

The above detailed description of embodiments of the disclosure is notintended to be exhaustive or to limit the teachings to the precise formdisclosed above. While specific embodiments of, and examples for, thedisclosure are described above for illustrative purposes, variousequivalent modifications are possible within the scope of thedisclosure, as those skilled in the relevant art will recognize. Forexample, while processes or blocks are presented in a given order,alternative embodiments may perform routines having steps, or employsystems having blocks, in a different order, and some processes orblocks may be deleted, moved, added, subdivided, combined, and/ormodified to provide alternative or subcombinations. Each of theseprocesses or blocks may be implemented in a variety of different ways.Also, while processes or blocks are at times shown as being performed inseries, these processes or blocks may instead be performed in parallel,or may be performed at different times. Further, any specific numbersnoted herein are only examples: alternative implementations may employdiffering values or ranges.

The teachings of the disclosure provided herein can be applied to othersystems, not necessarily the system described above. The elements andacts of the various embodiments described above can be combined toprovide further embodiments.

Any patents and applications and other references noted, including anythat may be listed in accompanying filing papers, are incorporatedherein by reference. Aspects of the disclosure can be modified, ifnecessary, to employ the systems, functions, and concepts of the variousreferences described above to provide yet further embodiments of thedisclosure.

These and other changes can be made to the disclosure in light of theabove Detailed Description. While the above description describescertain embodiments of the disclosure, and describes the best modecontemplated, no matter how detailed the above appears in text, theteachings can be practiced in many ways. Details of the system may varyconsiderably in its implementation details, while still beingencompassed by the subject matter disclosed herein. As noted above,particular terminology used when describing certain features or aspectsof the disclosure should not be taken to imply that the terminology isbeing redefined herein to be restricted to any specific characteristics,features, or aspects of the disclosure with which that terminology isassociated. In general, the terms used in the following claims shouldnot be construed to limit the disclosure to the specific embodimentsdisclosed in the specification, unless the above Detailed Descriptionsection explicitly defines such terms. Accordingly, the actual scope ofthe disclosure encompasses not only the disclosed embodiments, but alsoall equivalent ways of practicing or implementing the disclosure underthe claims.

While certain aspects of the disclosure are presented below in certainclaim forms, the inventors contemplate the various aspects of thedisclosure in any number of claim forms. For example, while only oneaspect of the disclosure is recited as a means-plus-function claim under35 U.S.C. § 112, ¶ 6, other aspects may likewise be embodied as ameans-plus-function claim, or in other forms, such as being embodied ina computer-readable medium. (Any claims intended to be treated under 35U.S.C. § 112, ¶ 6 will begin with the words “means for”.) Accordingly,the applicant reserves the right to add additional claims after filingthe application to pursue such additional claim forms for other aspectsof the disclosure.

What is claimed is:
 1. A method of optimizing traffic on a mobiledevice, comprising: determining that an application is inactive based onhistorical behavior of the application; blocking traffic originatingfrom or directed towards the application that is determined to beinactive based on historical behavior.
 2. The method of claim 1, whereinblocking traffic further includes blocking traffic after a period oftime that the screen of the mobile device has been off.
 3. The method ofclaim 1, wherein blocking traffic further includes blocking trafficbased on state of resources of the mobile device.
 4. The method of claim1, wherein blocking traffic further includes blocking traffic based oncost of the application.
 5. The method of claim 1, wherein, beforeblocking traffic originating from or directed towards the inactiveapplication, the method includes beginning polling offload optimization.6. The method of claim 1, wherein, before blocking traffic originatingfrom or directed towards the inactive application, the method includesaligning transactions from different applications on the same radioconnection.
 7. The method of claim 1, further including applying asignaling optimization strategy to background traffic that is differentthan an applied signaling optimization strategy of foreground traffic.8. The method of claim 1, wherein blocking traffic originating from ordirected towards the inactive application is stopped when a backlight ofthe mobile device is on.
 9. The method of claim 1, wherein blockingtraffic originating from or directed towards the inactive application isstopped when the mobile device screen is on.
 10. The method of claim 9,wherein, when an application stays in the background beyond aconfigurable timeout value, blocking traffic originating from ordirected towards the inactive application resumes.
 11. The method ofclaim 1, wherein the historical behavior includes a determination ofpoll intervals and patterns related to historical traffic.
 12. Themethod of claim 1, wherein blocking traffic originating from or directedtowards the inactive application is stopped when a push message isreceived.
 13. The method of claim 1, wherein an application behaviordetector on the mobile device determines that the application isinactive based on the historical behavior of the application, and theapplication behavior detector detects whether an application isoperating in the background or foreground.
 14. The method of claim 1,wherein blocking traffic originating from or directed towards theinactive application comprises blocking for a portion of time andceasing blocking for a remaining portion of time.
 15. A mobile devicehaving computer executable instructions stored thereon and configuredto: determine that an application is inactive based on historicalbehavior of the application; and block traffic originating from ordirected towards the application that is determined to be inactive basedon historical data.
 16. The mobile device of claim 15, wherein themobile device is configured to block traffic after a period of time thatthe screen of the mobile device has been off.
 17. The mobile device ofclaim 15, wherein the mobile device is configured to block traffic basedon state of resources of the mobile device.
 18. The mobile device ofclaim 15, wherein the mobile device is configured to block traffic basedon cost of the application.
 19. The mobile device of claim 15, wherein,before blocking traffic originating from or directed towards theinactive application, the mobile device is configured to begin pollingoffload optimization.
 20. The mobile device of claim 15, wherein, beforeblocking traffic originating from or directed towards the inactiveapplication, the mobile device is configure to align transactions fromdifferent applications on the same radio connection.